1. Field of the Invention
The present invention generally relates to an integrated circuit (IC) card system using an IC card and, more particularly, to a method of loading a card application program into an IC card and executing it.
2. Discussion of Background
Multifunction IC cards into which plural services can be loaded are increasingly replacing conventional type magnetic cards. A card issuer mainly manages a multifunction IC card. The card issuer often determines beforehand the application programs (APs) to be loaded into the IC card.
Regarding evaluating the combination of various cards and APs, a method involving a specification decision group related to an IC card of Global Platform (GP) is disclosed in GlobalPlatform Systems Profiles 1.1.0, published Sep. 2, 2003.
FIG. 1 shows a system configuration that automatically discriminates the right combination of an IC card and an AP in IC card management service proposed by GP. The outline of components of this conventional system is described below.
A card issue management system 101 manages information related to an IC card and the information of a card user and executes the card issue service. The card issue management system 101 manages a card issue management database (DB) 121. Card profile information 122 is managed in the corresponding DB. Card profile information 122 is attribute information related to the card. Card profile information 122 is a generic name for information used for the management of the card by the card issue management system 101. Card profile information 122 also includes basic data such as card identification (ID) and card capacity, as well as data that dynamically varies such as the list information of APs currently loaded into the card. Particularly, in this case, it is characteristic that data called card policy 123 is included. The card policy 123 is a requisite requested of another entity such as an AP by the card, for example, a requisite that the capacity of an AP shall be 4 KB or less and the type of the AP shall be an AP corresponding to Java®Card. The card policy is included in the card profile information 122. A card profile acquisition processor 124 is provided with logic for returning the corresponding card profile in response to a request from an external system.
A service provider management system 102 manages information related to the AP and the information of a service user and provides service. The service provider management system 102 manages a service provider management database 131, in which AP profile information 132 is managed. The AP profile information 132 is attribute information related to the AP. AP profile information 132 is a generic name for information used for the management of the AP by the service provider management system 102. The AP profile information 132 also includes basic data such as card identification (ID) and the name of the AP, as well as data that dynamically varies such as whether the AP is run or not. Like the card profile information 122, the AP profile information 132 includes an AP policy 133. The AP policy 133 is a requisite requested of another entity such as a card by the AP, for example, a requisite that the EEPROM capacity of the card shall be 16 KB or more and the platform of the card shall be Java®Card. An AP profile acquisition processor 134 is provided with logic for returning the corresponding AP profile in response to a request from an external system.
A collator system 103 is a system for collecting a profile in response to a request from a user 111 and for determining whether a policy included in the profile is met or not. The collator system 103 includes profile collection logic 141 and a policy determination processor 142. The profile collection logic 141 is provided with logic for requesting and acquiring card profile information 122 of the card issue management system 101 and requesting and acquiring AP profile information 132 of the service provider management system 102. The policy determination processor 142 includes logic for analyzing an acquired profile, for determining whether each policy is met or not, and for providing the result to the user.
The card issue management system 101, the service provider management system 102 and the collator system 103 exchange information via a network such as a public network, via a network including a common carrier leased line, or via mailing or handing a document and an information record medium. The terminal and the server of each system exchange information via a public network or via a network including a leased line.
Each of the above-mentioned systems is provided with a processor, but they are realized and operated as a computer program.
Next, the problem of a conventional type system will be described using the operational procedure of a process for determining whether the loading of an AP into an IC card is allowed in the above-mentioned system or not for an example.
When it is determined whether a desired AP can be loaded into a card 110 which the user 111 owns or not, the collator system is requested to determine whether the AP can be loaded or not (a step 151). For a concrete request method, there are Web access from a home PC, access from a terminal installed at a shop, and access via telephone inquiry. The collator system 103 acquires the corresponding card profile information 122 from the card issue management system 101 using the ID of the card owned by the user as a key (steps 152, 153). Similarly, the collator system 103 acquires the corresponding AP profile information from the service provider management system using application identification (AID) of the AP desired by the user as a key (steps 154, 155).
The collator system 103 verifies whether a card policy in the acquired card profile is met or not using information in the AP profile. For example, when the card policy is that the capacity of the AP shall be 4 KB or less, the collator system 103 checks an AP capacity item in the AP profile and determines whether the capacity is 4 KB or less or not. Similarly, the collator system verifies whether an AP policy in the AP profile is met or not by use of information in the card profile. When the AP policy is that the EEPROM capacity of the card shall be 16 KB or more, the collator system 103 checks an EEPROM capacity item in the card profile and determines whether the EEPROM capacity is 16 KB or more or not. The collator system 103 determines all policies and provides the result to the user (a step 156). Profile information including policies is represented in extensible markup language (XML).
If the types of IC cards increase, various APs are accordingly developed and can be provided. For versions are upgraded, loading may be impossible depending upon the combination of a card and an AP. Therefore, managing the combination of a loadable card and an AP becomes an intricate task for a card manager.
The AP can be loaded or deleted into/from a multifunction IC card after the card is issued to a user. It is assumed that the user freely selects the AP and repeatedly loads or deletes it. Therefore, it is estimated that it will be the essential service of a card issue manager to dynamically present which AP can be loaded to the user at real time.
A problem in a system proposed by a GP is that all items of profile information are required to be acquired.
The collator system acquires the information of all items defined as a profile because the contents of a policy are not known until the collator system receives a card policy included in a card profile and an AP policy included in an AP profile. Hereby, a problem related to security occurs. That is, every time a policy is determined, information unnecessary for determination is all provided to an external system. Besides, a problem in efficiency caused by differences in transmitted/received data capacity also occurs. When the policy of a whole IC card is determined in response to a request from a user, no large difference is made. However, when an IC card, the policy of which is to be determined, has large capacity and, accordingly, there are a large number of profiles for the collator to acquire, as in the case of a batch process, the data capacity of each profile information item is a large problem for efficiency of the system.
Another problem in the system proposed by the GP is that the format of profile information is fixed.
Profile information is information considered to be managed in the existent system, such as card ID, card capacity in the case of a card profile, AID, and the name of an AP in the case of an AP profile as described above. However, in a conventional type method, the format of each profile collected by the collator system 103 is required to be unified in the same format. Also, the card issue management system and the service provider management system are required to create a new DB or to create profile information according to the format beforehand. Creating a new DB has a problem of man-hours. Creating profile information requires creating profile information corresponding to the change of DB information at real time, which is difficult.